Many applications require a minimum amount of resource to be useful. One example is traditional voice telephony that below either a target minimum bandwidth or above a maximum delay becomes unusable. During call set-up in traditional fixed telecom networks (e.g., the PSTN), a signaling channel first checks that sufficient resources exist between the caller and callee before admitting the call and ringing the callee in the case of voice. If there is insufficient resource then the call is refused with a network busy signal. The resource availability is a precondition for the session to be set-up. This model has continued into the Internet world to ensure that Voice over IP applications can offer an equivalent user-experience to the PSTN, and so that VoIP can successfully interwork with the PSTN. However, many IP multimedia sessions would not require such a strict model.
A SIP Working Group Internet Draft Document: <draft-ietf-sip-manyfolks-resource-02> dated August 2001, hereinafter “the Draft” describes known art on the support of preconditions in the Internet signaling plane. The Draft may be obtained from the Internet Engineering Task Force (IETF) which can be contacted at www.ietf.org. This patent application is to be read and understood in the context of this existing Draft. The Draft describes how the Session Initiation Protocol (SIP) (session set-up signaling) can be used to carry the Session Description Protocol (SDP) (description of the session to be set-up) between Internet endpoints. The Draft specifically describes SDP preconditions whereby both SIP and SDP are extended to enable the two ends to negotiate and agree on the preconditions for the session. In addition, the signaling also establishes the order in which the two ends will attempt to meet those preconditions. The preconditions are direction specific in that they apply to the two endpoints A (the caller) and B (the callee) in the form of a precondition for resources and/or security from A to B, from B to A or for both directions. The preconditions attempt order can be B only, A then B or B then A then B (for example). The attempt order is determined through the exchange of confirm requests during the SDP exchanges. The results of each attempt on a precondition are then communicated to the other endpoint in a new SIP message defined in the Draft named the COMET (confirmation). An example of a typical SIP signaling flow is shown in FIG. 1.
The major problems with the existing model are as follows;                i) They have been designed specifically with the heavyweight VoIP requirement which leads to a large amount of signaling messages even for the simplest of preconditioned sessions.        ii) The capabilities of the endpoints for meeting offered preconditions are not fully exchanged so it is possible that excess signalling and set-up delay can be generated chasing unavailable options.        iii) The lead roles for the endpoints in meeting preconditions (first attempts) is not always agreed and so first attempts cannot necessarily execute in parallel. Parallel execution would reduce set-up times and would only be extended if the lead endpoint failed to meet a precondition due to probabilistic events (in which case the next endpoint would retry following a COMET). In addition, many lead role options are not available due to them not being fully negotiable as a result of the signalling design.        iv) Preconditions cannot generally start to be attempted until the pre-ring (pre-SIP 180 response) signaling has completed. This is a VoIP requirement (phone doesn't ring until resources are in place) but not typical across all IP applications and sessions. This enforces all sessions to incur the cost of multiple signaling messages and associated signaling delay even when both ends already have all preconditions in place (preconfigured resources or security associations).        v) Preconditions are negotiated only by endpoints and the Draft makes arguments as to why this is reasonable. However, the arguments are specific to the CableLabs DOCSIS DqoS architecture which provides QoS (Quality of Service) and security signaling between the hosts end to end to enable them alone to meet the preconditions. However, end to end QoS signaling is expensive and slow and not necessary in a large number of deployment scenarios. A more general model for preconditions signaling is therefore required.        